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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
IESG NOTE 


The IMAP extension described here assumes a particular means of using 
IMAP to support disconnected operation. However, this means of 
supporting disconnected operation is not yet documented. Also, there 
are multiple theories about how best to do disconnected operation in 
IMAP, and as yet, there is no consensus on which one should be 
adopted as a standard. 


This document is being approved as a Proposed Standard because it 
does not appear to have technical flaws in itelf. However, approval 
of this document as a Proposed Standard should not be considered an 
IETF endorsement of any particular means of doing disconnected 
operation in IMAP. 
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Le Abstract 


The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] 
provides a set of features intended to reduce the amount of time and 
resources used by some client operations. The features in UIDPLUS 
are primarily intended for disconnected-use clients. 


2. Conventions Used in this Document 


In examples, "C:" and "S:" indicate lines sent by the client and 
server respectively. 


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
in this document are to be interpreted as defined in "Key words for 
use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 


3.3 Introduction and Overview 


The UIDPLUS extension is present in any IMAP4 server implementation 
which returns "UIDPLUS" as one of the supported capabilities to the 
CAPABILITY command. The UIDPLUS extension contains one additional 
command and additional data returned with successful APPEND and COPY 
commands. 


Clients that wish to use the new command in UIDPLUS must of course 
first test for the presence of the extension by issuing a CAPABILITY 
command. Each of the features in UIDPLUS are optimizations; clients 
can provide the same functionality, albeit more slowly, by using 
commands in the base protocol. With each feature, this document 
recommends a fallback approach to take when the UIDPLUS extension is 
not supported by the server. 


4. Features 
4.1. UID EXPUNGE Command 


Arguments: message set 


Data: untagged responses: EXPUNGE 

Result: OK - expunge completed 
NO - expunge failure (e.g. permission denied) 
BAD - command unknown or arguments invalid 
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Example: 


4.2. 


The UID EXPUNGE command permanently removes from the currently 
selected mailbox all messages that both have the \Deleted flag set 
and have a UID that is included in the specified message set. If 
a message either does not have the \Deleted flag set or is has a 
UID that is not included in the specified message set, it is not 
affected. 


This command may be used to ensure that a replayed EXPUNGE command 
does not remove any messages that have been marked as \Deleted 
between the time that the user requested the expunge operation and 
the time the server processes the command. 


If the server does not support the UIDPLUS capability, the client 
should fall back to using the STORE command to temporarily remove 
the \Deleted flag from messages it does not want to remove. The 
client could alternatively fall back to using the EXPUNGE command, 
risking the unintended removal of some messages. 


C: A003 UID EXPUNGE 3000:3002 

S: * 3 EXPUNGE 

S: * 3 EXPUNGE 

S: * 3 EXPUNGE 

S: A003 OK UID EXPUNGE completed 


APPENDUID response code 


Successful APPEND commands return an APPENDUID response code in the 
tagged OK response. The APPENDUID response code contains as 
arguments the UIDVALIDITY of the destination mailbox and the UID 
assigned to the appended message. 


If the server does not support the UIDPLUS capability, the client can 
only discover this information by selecting the destination mailbox 
and issuing FETCH commands. 


Example: 


Myers 


A003 APPEND saved-messages (\Seen) {310} 
Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 
From: Fred Foobar <foobar@Blurdybloop.COM> 
Subject: afternoon meeting 

To: mooch@owatagu.siam.edu 

Message-Id: <B27397-0100000@Blurdybloop. COM> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 


Hello Joe, do you think we can meet at 3:30 tomorrow? 


nadqaaaaaagaaaaa 


A003 OK [APPENDUID 38505 3955] APPEND completed 
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4.3. COPYUID response code 


Successful COPY and UID COPY commands return a COPYUID response code 
in the tagged OK response whenever at least one message was copied. 
The COPYUID response code contains as an argument the UIDVALIDITY of 
the appended-to mailbox, a message set containing the UIDs of the 
messages copied to the destination mailbox, in the order they were 
copied, and a message containing the UIDs assigned to the copied 
messages, in the order they were assigned. Neither of the message 
sets may contain extraneous UIDs or the symbol ’*’. 


If the server does not support the UIDPLUS capability, the client can 
only discover this information by selecting the destination mailbox 
and issuing FETCH commands. 


Example: C: A003 COPY 2:4 MEETING 
S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done 
C: A003 UID COPY 305:310 MEETING 
S: A003 OK Done 
Diss Formal Syntax 


The following syntax specification uses the augmented Backus-Naur 
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 
Non-terminals referenced but not defined below are as defined by 
[IMAP4]. 


Except as noted otherwise, all alphabetic characters are case- 
insensitive. The use of upper or lower case characters to define 
token strings is for editorial clarity only. Implementations MUST 
accept these strings in a case-insensitive fashion. 


resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid 


resp_code_copy "COPYUID" SPACE nz_number SPACE set SPACE set 


uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set 
6. References 
[IMAP 4] Crispin, M., "Internet Message Access Protocol - 


Version 4rev1l", RFC 2060, December 1996. 


[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 
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hes Security Considerations 

There are no known security issues with this extension. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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